home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-11 / exoapi.zip / EXOINT86.ZIP / EXOINT86.DOC < prev   
Text File  |  1993-06-07  |  5KB  |  100 lines
  1. This file documents how the NanForum Toolkit function FT_INT86 was
  2. modified to support ExoSpace.
  3.  
  4. FT_INT86 is usually called to invoke software interrupts which execute
  5. in real mode.  Modification of FT_INT86 for ExoSpace required changes in
  6. two areas:
  7.  
  8. o   The call to __ftint86() was replaced by a call to the ExoSpace API
  9.     function ExoRMInterrupt().  A side effect of this was that the
  10.     FT_INT86 register structure had to be mapped onto the ExoSpace
  11.     EXOREGS register structure.
  12.  
  13. o   Pointers to strings or buffers had to be converted to real-mode
  14.     pointers which pointed to memory below 640K.  This was done using
  15.     the ExoSpace API function _xalloclow(), ExoRealPtr(), and
  16.     _xfreelow().
  17.  
  18. o   After the interrupt has returned, any buffers that were copied to
  19.     low memory are copied back so that if they were modified by the
  20.     interrupt handler, the results will be visible to the Clipper
  21.     application.
  22.  
  23. These changes are described in more detail below.
  24.  
  25.  
  26. __ftint86 -> ExoRMInterrupt()
  27. -----------------------------
  28.  
  29. The original real-mode FT_INT86 relied on a function called __ftint86(),
  30. implemented in assembler, to invoke the specified interrupt.  The
  31. ExoSpace API contains an equivalent function, ExoRMInterrupt, which was
  32. used instead of __ftint86().  ExoRMInterrupt is designed to invoke a
  33. real-mode interrupt from protected mode.
  34.  
  35. This change was necessary, among other reasons, because real-mode
  36. segment values cannot safely be loaded into the segment registers when
  37. in protected mode.  By loading the required register values into an
  38. instance of the EXOREGS register structure, this problem is circumvented.
  39. Since FT_INT86 already made use of such an approach for other reasons,
  40. it was relatively easy to replace the call to __ftint86 with a call to
  41. ExoRMInterrupt.  The biggest issue that had to be handled was mapping
  42. the register structure used by FT_INT86 onto the structure required by
  43. ExoRMInterrupt.  This was done with an array of offsets, regOff.  The
  44. macros setReg() and getReg() were used to clean up the syntax of
  45. register access via this array.
  46.  
  47.  
  48. Buffer copying and pointer conversion (_xalloclow(), ExoRealPtr())
  49. ------------------------------------------------------------------
  50.  
  51. If a pointer to a string is passed to FT_INT86, in either the DS:rr or
  52. ES:rr registers (where rr is a register containing an offset value),
  53. action must be taken to ensure that the string being pointed to exists
  54. in the first 640K, and a real-mode pointer to the string must be passed
  55. to the interrupt being invoked.
  56.  
  57. In the ExoSpace version of FT_INT86, this has been done by using the API
  58. function _xalloclow() to allocate the required amount of memory in the
  59. first 640K.  _xalloclow() returns a protected-mode pointer to the allocated
  60. memory, which can then be used to copy the data into newly allocated memory.
  61. Finally, the protected-mode pointer returned by _xallocnew() is converted
  62. into a real-mode pointer using the function ExoRealPtr().  The real-mode
  63. pointer is placed into the EXOREGS register structure in the appropriate
  64. place.
  65.  
  66. Note that the approach used here is a conservative one suited to the
  67. generic nature of FT_INT86.  When strings are involved, memory is
  68. allocated and deallocated each time an interrupt is invoked.  In other
  69. circumstances, a more efficient alternative might be to allocate permanent
  70. buffers in low memory using _xalloclow().  These buffers could be made
  71. large enough to accomodate the largest string that you would ever pass to
  72. the software interrupts you are using.  You could then avoid continually
  73. allocating and deallocating these buffers.  Another area which can be
  74. optimized is the need to copy the string from extended memory into low
  75. memory.  If you have sufficient control over the software concerned, you
  76. can ensure that the initial allocation uses _xalloclow(), obviating the
  77. need to copy the string before signalling the interrupt.  In all cases,
  78. however, ExoRealPtr() must be used to obtain a real-mode pointer to the
  79. buffers.  If permament buffers were maintained, however, you would only
  80. need to call ExoRealPtr() once for each such buffer.
  81.  
  82.  
  83. Copying the buffers back
  84. ------------------------
  85.  
  86. After the interrupt has returned, any buffers that were copied to low
  87. memory are copied back so that if they were modified by the interrupt
  88. handler, the results will be visible to the Clipper application.
  89.  
  90. _storclen with a NULL pointer is used to prevent any changes to the
  91. string from affecting other references to the same string.  This is
  92. also done in the original version of FT_INT86.
  93.  
  94. The low memory buffer is then copied back to the correct place.
  95. Finally, the memory which was allocated with _xalloclow() is freed using
  96. the ExoSpace API function _xfreelow().
  97.  
  98.  
  99. <*** End of File ***>
  100.